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DETAILED ACTION 

1 . The amendment filed 2/17/2005 has been placed of record in the file. 

2. Claims 59-66 have been added. 

3. Claims 1-66 are now pending. 

4. The applicant's arguments, see pgs. 14-15 of the amendment filed 2/17/2005 and the 
interview summary of the telephone interview conducted 2/16/2005, with respect to the rejection 
of claims 1-4, 8-10, 14-16, 21-23, 25, 29, 30, 35-40, 42, and 46-58 under 35 U.S.C. 102(e) and 
the rejection of claims 5-7, 11-13, 17-20, 24, 26-28, 31-34, 41, and 43-45 under 35 U.S.C. 103(a) 
have been fully considered and are persuasive. Therefore, the rejections have been withdrawn. 
Upon further consideration, a new grounds of rejection is made as will be discussed in detail 
below. 

Claim Rejections - 35 USC §103 

5. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

6. Claims 1-4, 8-10, 14-16, 21-23, 25, 29, 30, 35-40, 42, and 46-66 are rejected under 35 
U.S.C. 103(a) as being unpatentable over Ketcham (U.S. Patent Number 6,721,334) in view of 
Pereira (U.S. Patent Number 5,781,72©. 

7. Ketcham disclosed a method for improving the efficiency of a packet-based network by 
using aggregate packets. In an analogous art, Pereira disclosed a method for managing polling 
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traffic in a set of connection oriented sessions between end stations in a network. Both systems 
deal with data transfer from at least one end node, through a first router or edge device, through a 
second router or edge device, and to at least one second end node. 

8. Concerning the independent claims, although Ketcham describes a system in which 
different types of data packets can be aggregated together, he did not explicitly state the use of a 
keep-alive message or poll request. However, Pereira's system is focused on the polling of 
point-to-point devices and explicitly states the use of a poll request from a first to a second end 
system and a poll response from the second to the first end system. It would have been obvious 
to one of ordinary skill in the art at the time of the applicant's invention to modify the system of 
Ketcham by adding the ability to use keep-alive messages as the data packets as provided by 
Pereira. Here the combination would satisfy the need for an improved connection oriented 
protocol for systems that maintain a number of end users that share a common link. See Pereira, 
column 4, lines 12-17. This rationale also applies to those dependent claims utilizing the same 
combination. 

9. Thereby, the combination of Ketcham and Pereira discloses: 
• <Claim 1> 

A method of processing a plurality of keep-alive messages generated by a corresponding 
plurality of end systems, each of said plurality of keep-alive messages being designed to 
request the status of a corresponding point to point (PPP) session implemented on a 
communication network, said method comprising: receiving in an aggregation device 
(Ketcham, figure 4, item 308) said plurality of keep-alive messages (Pereira, column 4, 
lines 31-34); generating in said aggregation device an aggregated request packet which 
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indicates that the status of said PPP sessions is requested (Ketcham, column 7, line 62 
through column 8, line 4, wherein the aggregated packet contains the poll requests as 
disclosed by Pereira); and sending said aggregated request packet on said communication 
network to a peer aggregation device (Ketcham, figure 4, item 3 14). 

• <Claim 2> 

The method of claim 1, further comprising: receiving said aggregated request packet in 
said peer aggregation device (Ketcham, column 8, lines 15-22); indicating the status of 
said plurality of sessions in an aggregated reply packet (Pereira, column 6, lines 1-6, 
wherein Pereira 5 s response polls may be aggregated at Ketcham' s router 314); and 
sending said aggregated reply packet to said aggregation device (Ketcham, figure 4, 
inherently data packets can also flow from router 314 to router 308). 

• <Claim 3> 

The method of claim 1, further comprising receiving in said aggregation device an 
aggregated reply packet from said peer aggregation device, wherein said aggregated reply 
packet indicates the status of at least some of said plurality of PPP sessions (Pereira, 
column 6, lines 1-6). 

• <Claim 4> 

The method of claim 3, further comprising sending from said aggregation device a proxy 
keep-alive reply message to one of said plurality of end systems originating a 
corresponding one of said keep alive-messages without waiting for said aggregated reply 
packet (Pereira, column 5, lines 45-47). 
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• <Claim 8> 

The method of claim 1, wherein said communication network is implemented using one 
of frame relay, ATM and IP networks (Ketcham, column 1, lines 33-48). 

• <Claim9> 

The method of claim 1, wherein said aggregation device is one of a network access server 
and home gateway (Ketcham, column 4, lines 37-43). 

• <Claim 10> 

A method of processing an aggregated request packet in an aggregation device, wherein 
said aggregated request packet indicates that the status of a plurality of point-to-point 
sessions are requested, said method comprising: examining said aggregated request 
packet to determine said plurality of point-to-point sessions (Ketcham, column 8, lines 
15-22, wherein the aggregated packet contains the poll requests as disclosed by Pereira); 
determining the status of each of said plurality of point-to-point sessions (Pereira, column 
6, lines 1-6 and 50-55); generating an aggregated reply packet indicating the status of 
said plurality of point- to-point sessions (Pereira, column 6, lines 1-6, wherein Pereira's 
response polls may be aggregated at Ketcham's router 314); and sending said aggregated 
reply packet to said peer aggregation device (Ketcham, figure 4, inherently data packets 
can also flow from router 3 14 to router 308). 

• <Claim 14> 

The method of claim 10, wherein said aggregation device comprises one of a network 
access server (NAS) and a home gateway implemented in a communication network 
(Ketcham, column 4, lines 37-43). 
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• <Claiml5> 

An aggregation device for processing a plurality of keep-alive messages generated by a 
corresponding plurality of end systems, each of said plurality of keep-alive messages 
being designed to request the status of a corresponding point to point (PPP) session 
implemented on a communication network, said aggregation device comprising: an input 
interface receiving said plurality of keep-alive messages (Ketcham, figure 4, item 308 
and Pereira, column 4, lines 31-34); a message aggregator coupled to said input interface, 
said message aggregator examining said plurality of message and generating data 
according to a format indicating that the status of said PPP sessions is requested 
(Ketcham, column 7, line 62 through column 8, line 4, wherein the aggregated packet 
contains the poll requests as disclosed by Pereira); and an output interface sending an 
aggregated request packet on said communication network to a peer aggregation device, 
said aggregated request packet containing said data generated by said message aggregator 
(Ketcham, figure 4, item 314). 

• <Claim 16> 

The aggregation device of claim 15, further comprising an encapsulator encapsulating 
said data in a packet suitable for transmission on said communication network (Pereira, 
column 2, lines 19-25, wherein encapsulation is inherent to PPP). 

• <Claim21> 

An aggregation device for processing a plurality of keep-alive messages generated by a 
corresponding plurality of end systems, each of said plurality of keep-alive messages 
being designed to request the status of a corresponding point to point (PPP) session 
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implemented on a communication network, said aggregation device comprising: first 
means for receiving said plurality of keep-alive messages (Ketcham, figure 4, item 308 
and Pereira, column 4, lines 31-34); means for generating an aggregated request packet 
which indicates that the status of said PPP sessions is requested (Ketcham, column 7, line 
62 through column 8, line 4, wherein the aggregated packet contains the poll requests as 
disclosed by Pereira); and means for sending said aggregated request packet on said 
communication network to a peer aggregation device (Ketcham, figure 4, item 314). 

• <Claim 22> 

The aggregation device of claim 21, further comprising second means for receiving an 
aggregated reply packet from said peer aggregation device (Ketcham, figure 4, inherently 
data packets can also flow from router 314 to router 308), wherein said aggregated reply 
packet indicates the status of at least some of said plurality of PPP sessions (Pereira, 
column 6, lines 1-6). 

• <Claim 23> 

The aggregation device of claim 22, further comprising means for sending a proxy keep- 
alive reply message to one of said plurality of end systems originating a corresponding 
one of said keep alive-messages without waiting for said aggregated reply packet 
(Pereira, column 5, lines 45-47). 

• <Claim 25> 

An aggregation device for processing an aggregated request packet, wherein said 
aggregated request packet indicates that the status of a plurality of point-to-point sessions 
are requested, said aggregation device comprising: means for examining said aggregated 
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request packet to determine said plurality of point-to-point sessions (Ketcham, column 8, 
lines 15-22, wherein the aggregated packet contains the poll requests as disclosed by 
Pereira); means for determining the status of each of said plurality of point-to-point 
sessions (Pereira, column 6, lines 1-6 and 50-55); means for generating an aggregated 
reply packet indicating the status of said plurality of point-to-point sessions (Pereira, 
column 6, lines 1-6, wherein Pereira's response polls may be aggregated at Ketcham's 
router 3 14); and means for sending said aggregated reply packet to said peer aggregation 
device (Ketcham, figure 4, inherently data packets can also flow from router 314 to router 
308). 

• <Claim 29> 

The aggregation device of claim 25, wherein said aggregation device comprises one of a 
network access server (NAS) and a home gateway implemented in a communication 
network (Ketcham, column 4, lines 37-43). 

• <Claim 30> 

An aggregation device for processing an aggregated request packet, wherein said 
aggregated request packet indicates that the status of a plurality of point-to-point sessions 
are requested, said aggregation device comprising: an input interface receiving said 
aggregated request packet (Ketcham, figure 4, item 3 14, wherein the aggregated packet 
contains the poll requests as disclosed by Pereira); a de-encapsulator examining said 
aggregated request packet to determine that said aggregated request packet relates to 
requesting the status of point-to-point sessions (Ketcham, column 8, lines 15-22); a reply 
generator determining the status of each of said plurality of point-to-point sessions, and 
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generating an aggregated reply packet indicating the status of said plurality of point-to- 
point sessions (Pereira, column 6, lines 1-6, wherein Pereira 5 s response polls may be 
aggregated at Ketcham's router 3 14); and an output interface sending said aggregated 
reply packet to said peer aggregation device (Ketcham, figure 4, inherently data packets 
can also flow from router 3 14 to router 308). 

• <Claim35> 

The aggregation device of claim 30, further comprising a keep-alive processor coupled to 
said de-encapsulator, wherein said keep-alive processor examines said aggregated request 
packet to determine that status of point-to-point sessions is requested and causes said 
reply generator to generate said aggregated reply packet (Ketcham, column 8, lines 15-22 
and Pereira, column 6, lines 1-6). 

• <Claim 36> 

The aggregation device of claim 30, wherein said aggregation device comprises one of a 
network access server (NAS) and a home gateway implemented in a communication 
network (Ketcham, column 4, lines 37-43). 

• <Claim 37> 

A computer-readable medium carrying one or more sequences of instructions for causing 
a aggregation device to process a plurality of keep-alive messages generated by a 
corresponding plurality of end systems, each of said plurality of keep-alive messages 
being designed to request the status of a corresponding point to point (PPP) session 
implemented on a communication network, wherein execution of said one or more 
sequences of instructions by one or more processors contained in said aggregation device 
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causes said one or more processors to perform the actions of: receiving in an aggregation 
device (Ketcham, figure 4, item 308) said plurality of keep-alive messages (Pereira, 
column 4, lines 31-34); generating in said aggregation device an aggregated request 
packet which indicates that the status of said PPP sessions is requested (Ketcham, column 
7, line 62 through column 8, line 4, wherein the aggregated packet contains the poll 
requests as disclosed by Pereira); and sending said aggregated request packet on said 
communication network to a peer aggregation device (Ketcham, figure 4, item 314). 

• <Claim38> 

The computer-readable medium of claim 37, further comprising: receiving said 
aggregated request packet in said peer aggregation device (Ketcham, column 8, lines 15- 
22); indicating the status of said plurality of sessions in an aggregated reply packet 
(Pereira, column 6, lines 1-6, wherein Pereira's response polls may be aggregated at 
Ketcham' s router 3 14); and sending said aggregated reply packet to said aggregation 
device (Ketcham, figure 4, inherently data packets can also flow from router 314 to router 
308). 

• <Claim 39> 

The computer-readable medium of claim 37, further comprising receiving in said 
aggregation device an aggregated reply packet from said peer aggregation device, 
wherein said aggregated reply packet indicates the status of at least some of said plurality 
of PPP sessions (Pereira, column 6, lines 1-6). 
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• <Claim 40> 

The computer-readable medium of claim 39, further comprising sending a proxy keep- 
alive reply message to one of said plurality of end systems originating a corresponding 
one of said keep alive-messages without waiting for said aggregated reply packet 
(Pereira, column 5, lines 45-47). 

• <Claim42> 

A computer-readable medium carrying one or more sequences of instructions for causing 
an aggregation device to process an aggregated request packet, wherein said aggregated 
request packet indicates that the status of a plurality of point-to-point sessions are 
requested, wherein execution of said one or more sequences of instructions by one or 
more processors contained in said aggregation device causes said one or more processors 
to perform the actions of: examining said aggregated request packet to determine said 
plurality of point-to-point sessions (Ketcham, column 8, lines 15-22, wherein the 
aggregated packet contains the poll requests as disclosed by Pereira); determining the 
status of each of said plurality of point-to-point sessions (Pereira, column 6, lines 1-6 and 
50-55); generating an aggregated reply packet indicating the status of said plurality of 
point- to-point sessions (Pereira, column 6, lines 1-6, wherein Pereira's response polls 
may be aggregated at Ketcham's router 314); and sending said aggregated reply packet to 
said peer aggregation device (Ketcham, figure 4, inherently data packets can also flow 
from router 314 to router 308). 
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• <Claim 46> 

The computer-readable medium of claim 42, wherein said aggregation device comprises 
one of a network access server (NAS) and a home gateway implemented in a 
communication network (Ketcham, column 4, lines 37-43). 

• <Claim 47> 

A communication network comprising: a first aggregation device (Ketcham, figure 4, 
item 308) receiving a plurality of keep-alive messages (Pereira, column 4, lines 31-34) 
generated by a corresponding plurality of end systems, each of said plurality of keep- 
alive messages being designed to request the status of a corresponding point to point 
(PPP) session implemented on said communication network, said first aggregation device 
generating an aggregated request packet which indicates that the status of said PPP 
sessions is requested (Ketcham, column 7, line 62 through column 8, line 4, wherein the 
aggregated packet contains the poll requests as disclosed by Pereira), and sending said 
aggregated request packet (Ketcham, column 7, line 62 through column 8, line 4); and a 
peer aggregation device (Ketcham, figure 4, item 314) receiving said aggregated request 
packet and indicating the status of said plurality of sessions in an aggregated reply packet 
(Pereira, column 6, lines 1-6, wherein Pereira' s response polls may be aggregated at 
Ketcham 5 s router 314), said peer aggregation packet sending said aggregated reply packet 
to said first aggregation device (Ketcham, figure 4, inherently data packets can also flow 
from router 3 14 to router 308). 



Application/Control Number: 09/785,884 Page 13 

Art Unit: 2155 

• <Claim 48> 

The communication network of claim 47, wherein said first aggregation device is located 
at an edge of said communication networks (Ketcham, figure 4, item 308). 

• <Claim 49> 

The communication network of claim 48, further comprising an access network coupling 
said first aggregation device to said corresponding plurality of end systems, wherein said 
plurality of keep-alive messages are received on said access network (Ketcham, figure 4, 
item 106). 

• <Claim 50> 

The communication network of claim 49, wherein said first aggregation device and said 
peer aggregation device respectively comprise a network access server (NAS) and a 
home gateway (Ketcham, column 4, lines 37-43). 

• <Claim51> 

The method of claim 1, wherein said aggregation device is in the path of all of said 
plurality of PPP sessions (Ketcham, figure 4, item 308). 

• <Claim 52> 

The method of claim 10, wherein said aggregation device is in the path of all of said 
plurality of PPP sessions (Ketcham, figure 4, item 308). 

• <Claim 53> 

The invention of claim 15, wherein said aggregation device is in the path of all of said 
plurality of PPP sessions (Ketcham, figure 4, item 308). 
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• <Claim 54> 

The invention of claim 21, wherein said aggregation device is in the path of all of said 
plurality of PPP sessions (Ketcham, figure 4, item 308). 

• <Claim 55> 

The invention of claim 25, wherein said aggregation device is in the path of all of said 
plurality of PPP sessions (Ketcham, figure 4, item 308). 

• <Claim 56> 

The invention of claim 30, wherein said aggregation device is in the path of all of said 
plurality of PPP sessions (Ketcham, figure 4, item 308). 

• <Claim 57> 

The computer readable medium claim 37, wherein said aggregation device is in the path 
of all of said plurality of PPP sessions (Ketcham, figure 4, item 308). 

• <Claim 58> 

The computer readable medium claim 42, wherein said aggregation device is in the path 
of all of said plurality of PPP sessions (Ketcham, figure 4, item 308). 

• <Claim 59> 

The method of claim 1, wherein said aggregation device is physically separate from said 
plurality of end systems (Ketcham, figure 4, item 308). 

• <Claim60> 

The method of claim 10, wherein said aggregation device is physically separate from said 
plurality of end systems (Ketcham, figure 4, item 308). 



Application/Control Number: 09/785,884 Page 1 5 

Art Unit: 2155 

• <Claim61> 

The invention of claim 15, wherein said aggregation device is physically separate from 
said plurality of end systems (Ketcham, figure 4, item 308). 

• . <Claim62> 

The invention of claim 21, wherein said aggregation device is physically separate from 
said plurality of end systems (Ketcham, figure 4, item 308). 

• <Claim 63> 

The invention of claim 25, wherein said aggregation device is physically separate from 
said plurality of end systems (Ketcham, figure 4, item 308). 

• <Claim 64> 

The invention of claim 30, wherein said aggregation device is physically separate from 
said plurality of end systems (Ketcham, figure 4, item 308). 

• <Claim 65> 

The computer readable medium claim 37, wherein said aggregation device is physically 
separate from said plurality of end systems (Ketcham, figure 4, item 308). 

• <Claim 66> 

The computer readable medium claim 42, wherein said aggregation device is physically 
separate from said plurality of end systems (Ketcham, figure 4, item 308). 

Since the combination of Ketcham and Pereira discloses all of the above limitations, claims 1-4, 

8-10, 14-16, 21-23, 25, 29, 30, 35-40, 42, and 46-66 are rejected. 
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10. Claims 5-7, 11, 13, 17-19, 24, 26, 28, 31, 32, 34, 41, 43, and 45 are rejected under 35 
U.S.C. 103(a) as being unpatentable over Ketcham in view of Pereira, as applied above, further 
in view of Chao et al. (U.S. Patent Number 5,964,837), hereinafter referred to as Chao. 

1 1 . The combination of Ketcham and Pereira disclosed a method for managing polling traffic 
in a set of connection oriented sessions between end stations in a network that uses aggregation 
of packets. In an analogous art, Chao disclosed a method of monitoring the topology of a 
network using polling and event-monitoring. Just as the combination of Ketcham and Pereira, 
Chao's system is utilized in point-to-point networks. 

12. Concerning claim 5, although the combination of Ketcham and Pereira did not explicitly 
state that the use of a table to track the status of sessions in the network, Chao's main focus is a 
table or topology map, containing information about the operability of nodes in his system. It 
would have been obvious to one of ordinary skill in the art at the time of the applicant's 
invention to modify the combination of Ketcham and Pereira by adding a status table as provided 
by Chao. Here the combination satisfies the need for an improved method of monitoring a point- 
to-point network. See Chao, column 2, lines 15-24. This rationale also applies to other similar 
dependent claims utilizing the same combination. 

13. Thereby, the combination of Ketcham, Pereira, and Chao discloses: 
• <Claim 5> 

The method of claim 4, further comprising: maintaining a remote status table in said 
aggregation device, wherein said remote status table indicates the status of sessions 
supported by said aggregation device (Chao, column 5, lines 46-50); updating said 
remote status table with the information in said aggregated reply packet (Chao, column 6, 
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lines 1-13); and generating said proxy keep-alive reply according to said remote status 
table (Chao, column 6, lines 55-65). 

• <Claim 6> 

The method of claim 5, wherein said proxy keep-alive message indicates that the 
corresponding session is alive/OK when a first keep-alive message is received for the 
corresponding session (Pereira, column 10, lines 29-38). 

• <Claim 7> 

The method of claim 6, further comprising initializing the status of each of said session to 
alive/OK such that said proxy keep-alive message in response to said first keep-alive 
message indicates alive/OK status (Pereira, column 10, lines 18-28). 

• <Claimll> 

The method of claim 10, wherein said determining comprises accessing a local status 
table which contains the status information of at least some of said plurality of point- to- 
point sessions (Chao, column 8, lines 52-58). 

• <Claim 13> 

The method of claim 10, wherein said generating comprises setting a bit to one logical 
value to indicate that a corresponding one of said plurality of sessions is OK/alive, and to 
another logical value to indicate that said corresponding one of said plurality of session 
not OK/alive (Chao, column 5, lines 50-53). 

• <Claim 17> 

The aggregation device of claim 16, further comprising: a remote status table indicating 
the status of sessions supported by said aggregation device (Chao, column 5, lines 46- 
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50); and a de-aggregator receiving an aggregated reply packet from said peer aggregation 
device, wherein said aggregated reply packet indicates the status of at least some of said 
plurality of PPP sessions, said de-aggregator updating said remote status table with the 
information in said aggregated reply packet (Chao, column 6, lines 1-13). 

• <Claiml8> 

The aggregation device of claim 17, further comprising a proxy reply unit sending a 
proxy keep-alive reply message to one of said plurality of end systems originating a 
corresponding one of said keep alive-messages without waiting for said aggregated reply 
packet (Pereira, column 5, lines 45-47). 

• <Claim 19> 

The invention of claim 18, wherein said aggregation device comprises a network access 
server (Ketcham, column 4, lines 37-43). 

• <Claim 24> 

The aggregation device of claim 23, further comprising: means for maintaining a remote 
status table in said aggregation device, wherein said remote status table indicates the 
status of sessions supported by said aggregation device (Chao, column 5, lines 46-50); 
means for updating said remote status table with the information in said aggregated reply 
packet (Chao, column 6, lines 1-13); and means for generating said proxy keep-alive 
reply according to said remote status table (Chao, column 6, lines 55-65). 
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• <Claim 26> 

The aggregation device of claim 25, wherein said means for determining comprises 
means for accessing a local status table which contains the status information of at least 
some of said plurality of point-to-point sessions (Chao, column 8, lines 52-58). 

• <Claim 28> 

The aggregation device of claim 25, wherein said means for generating sets a bit in said 
aggregated reply packet to one logical value to indicate that a corresponding one of said 
plurality of sessions is OK/alive, and to another logical value to indicate that said 
corresponding one of said plurality of session not OK/alive (Chao, column 5, lines 50- 
53). 

• <Claim31> 

The aggregation device of claim 30, further comprising a local status table storing the 
status information of at least some of said plurality of point-to-point sessions, wherein 
said reply generator determines the status of said at least some of said plurality of point- 
to- point sessions by accessing said local status table (Chao, column 8, lines 52-58). 

• <Claim 32> 

The aggregation device of claim 31, further comprising a session manager updating the 
status of said plurality of point-to-point sessions in said local status table (Chao, column 
7, lines 64-66). 

• <Claim 34> 

The aggregation device of claim 30, wherein said reply generator sets a bit in said 
aggregated reply packet to one logical value to indicate that a corresponding one of said 
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plurality of sessions is OK/alive, and to another logical value to indicate that said 
corresponding one of said plurality of session not OK/alive (Chao, column 5, lines 50- 
53). 

• <Claim41> 

The computer-readable medium of claim 40, further comprising: maintaining a remote 
status table in said aggregation device, wherein said remote status table indicates the 
status of sessions supported by said aggregation device (Chao, column 5, lines 46-50); 
updating said remote status table with the information in said aggregated reply packet 
(Chao, column 6, lines 1-13); and generating said proxy keep-alive reply according to 
said remote status table (Chao, column 6, lines 55-65). 

• <Claim 43> 

The computer-readable medium of claim 42, wherein said determining comprises 
accessing a local status table which contains the status information of at least some of 
said plurality of point-to-point sessions (Chao, column 8, lines 52-58). 

• <Claim 45> 

The computer-readable medium of claim 42, wherein said generating comprises setting a 
bit to one logical value to indicate that a corresponding one of said plurality of sessions is 
OK/alive, and to another logical value to indicate that said corresponding one of said 
plurality of session not OK/alive (Chao, column 5, lines 50-53). 
Since the combination of Ketcham, Pereira, and Chao discloses all of the above limitations, 
claims 5-7, 11, 13, 17-19, 24, 26, 28,31,32, 34,41,43, and 45 are rejected. 
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14. Claims 12, 20, 27, 33, and 44 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Ketcham in view of Pereira further in view of Chao, as applied above, further in view of 
Simpson ("RFC 1661: Point-to-Point Protocol," July 1994). 

15. The combination of Ketcham, Pereira, and Chao disclosed a method for managing polling 
traffic in a set of connection oriented sessions between end stations in a point-to-point network 
by aggregating packets and maintaining a status table. In an analogous art, Simpson disclosed an 
overview of the point-to-point protocol. 

16. Concerning claim 12, although the combination of Ketcham, Pereira, and Chao did not 
explicitly teach the use of a magic number associated with each session, Simpson taught a magic 
number for use with the point-to-point protocol. It would have been obvious to one of ordinary 
skill in the art at the time of the applicant's invention to modify the combination of Ketcham, 
Pereira, and Chao by adding a magic number as provided by Simpson. Again the combination 
satisfies the need for an improved method of monitoring a point-to-point network. See Chao, 
column 2, lines 15-24. This rationale also applies to other similar dependent claims utilizing the 
same combination. 

17. Thereby, the combination of Ketcham, Pereira, Chao, and Simpson discloses: 
• <Claim 12> 

The method of claim 10, wherein said generating comprises including a client magic 
number associated with each of said plurality of point-to-point sessions (Simpson, pages 
45-47). 
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• <Claim 20> 

The aggregation device of claim 18, wherein said aggregated request packet contains a 
magic number related to each of the corresponding sessions (Simpson, pages 45-47). 

• <Claim 27> 

The aggregation device of claim 25, wherein said means for generating includes a client 
magic number associated with each of said plurality of point-to-point sessions (Simpson, 
pages 45-47). 

• <Claim 33> 

The aggregation device of claim 30, wherein said reply generator includes in said 
aggregated reply packet a client magic number associated with each of said plurality of 
point-to-point sessions (Simpson, pages 45-47). 

• <Claim 44> 

The computer-readable medium of claim 42, wherein said generating comprises 
including a client magic number associated with each of said plurality of point-to-point 
sessions (Simpson, pages 45-47). 

Since the combination of Ketcham, Pereira, Chao, and Simpson discloses all of the above 

limitations, claims 12, 20, 27, 33, and 44 are rejected. 
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Conclusion 

18. The prior art made of record and not relied upon is considered pertinent to the applicant's 
disclosure. 

• Natarajan et al. (U.S. Patent Number 6,304,546) disclosed a method for sending and 
receiving end-to-end bidirectional keep-alive messages using virtual circuits. 

• Belser et al. (U.S. Patent Number 6,449,279) disclosed a method for aggregating data 
flows over a pre-established path in order to reduce connections. 

• Goyal et al. (U.S. Patent Number 6,466,985) disclosed an intermediate network device 
for routing packets according to flow labels. 

• Natanson et al. (U.S. Patent Number 6,643,289) disclosed a method for notification of 
device status changes in a MPOA enabled ATM based network. 

• Bommareddy et al. (U.S. Patent Number 6,779,039) disclosed a method for routing 
message traffic using a cluster of routers sharing a single logical IP address. 

19. Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Victor Lesniewski whose telephone number is 571-272-3987. 
The examiner can normally be reached on Monday through Thursday. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Hosain Alam can be reached on 571-272-3978. The fax phone number for the . 
organization where this application or proceeding is assigned is 703-872-9306. 



Application/Control Number: 09/785,884 Page 24 

Art Unit: 2155 

Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 
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